This invention relates to computer software and more particularly to loading and executing program modules in the memory of a computer. Even more particularly, this invention relates to loading and executing program modules into a computer having a main memory and an expanded memory with bank switchable pages.
When the IBM personal computer was introduced in 1981, the addressable memory limit imposed by the hardware, and DOS operating system introduced along with it, was 640K bytes, where K is 1024. While this limitation was not significant at first, there was soon a need for more than the 640K memory that was available as main memory. As a consequence of this need several vendors developed a form of memory called expanded memory, and more commonly known as bank switched memory, with a size considerably in excess of the 640K available as main memory. This expanded memory is addressed not as main memory, but as a special page frame of 64K located at an address above the 640K limit. Although the expanded memory may be very large, only part of the expanded memory, the part switched into the page frame, may be directly addressed by the computer. The expanded memory is divided into pages of 16K, and I/O ports are used to select which 16K page of the expanded memory is accessible in each of the four 16K areas of the page frame. Subsequent versions of this expanded memory allowed the page frame to exceed 64K and allowed the page frame to be located at any address not containing main memory or I/O memory.
As the amount of software available for this computer has increased, the 640K limitation for programs has become more of a burden. Not only are user programs getting larger, a new type of software, called terminate and stay resident (TSR) software because it stays in memory after being loaded by a user, is now available to perform functions for a user while other software is running. The TSR software monitors keyboard input, and when a certain combination of keys is pressed, it takes over the machine from the user's currently running software to perform a request of the user. Since TSRs stay memory resident, they occupy part of the 640K total main memory available. Another type of code that stays memory resident is a DOS device driver. There is a device driver for each type of I/O device since the device drivers are the software that link the user code to the I/O device. Device drivers must stay memory resident because a user is allowed to use an I/O device at any time. Although there is a need in the art for using the expanded memory for executable code such as TSRs and device drivers, it has been widely thought that because the page frame was above the 640K limitation of DOS, the expanded memory could only be used for data and not for executable code. This idea has been published in an article by Ray Duncan entitled "Understanding Expanded Memory Subsystems", in The Waite Group's MS-DOS Papers for MS-DOS Developers and Power Users, Howard W. Sams Company, 1988, p. 538.
Another paper, "Expanded memory: Writing Programs That Break the 640K Barrier", in the Microsoft Systems Journal, Microsoft Corporation, March 1987, pp 21-32, has described a way of using expanded memory for executable code. The method described in this paper separates the code into a "kernel" and a "pseudo-overlay" --the kernel remains in main memory, while the pseudo-overlay is loaded into expanded memory. This method has several deficiencies. First, it fails if expanded memory is not available, so every program that uses it would have to be supplied in two versions, one for a machine that has expanded memory and a different version for a machine that does not have expanded memory. Secondly, this method requires that the kernel and pseudo-overlay be separate programs which are separately loadable by DOS. Thirdly, data cannot easily be shared by the kernel and pseudo-overlay since they are separate programs. A fourth deficiency is that this method does not remove its initialization code after performing initialization, so the code continues to occupy valuable memory all the time the TSR is loaded. Another deficiency with this method is that it cannot be used to write DOS device drivers because DOS device drivers are loaded at the same time DOS is loaded and the order of loading is such that the DOS device drivers are loaded before the DOS overlay function this method needs to load its pseudo-overlay. This method also requires that the code necessary to switch the context of the expanded memory, to bring the TSR pseudo-verlay software into the expanded memory page frame, be resident in each kernel, since no provision is made in the method for a kernel to call a common routine. Lastly, the method is deficient in that a user request to the TSR that has the user request data located in expanded memory will fail, since the TSR will switch the TSR pseudo-overlay pages into the page frame in place of the user pages containing the data, thus making the user data unavailable.
It is thus apparent that there is a need in the art for an improved method of accessing expanded memory that will allow executable code to be placed in expanded memory and further allow such code to be executed directly from such expanded memory. There is a need for such a method that recognizes whether or not expanded memory is available and loads and executes itself in main memory if no expanded memory is available. There is also a need for a method that allows a program module to be a single program so that the main memory resident portion and the expanded memory resident portion can share a data area. The method should also allow the shared data area to be located in either main memory or expanded memory. There is a further need for such a method that releases memory occupied by its initialization code after such code is performed. A further need in the art is for such a method that can be used for program modules written as DOS device drivers. Yet another need is for a method that will share the code necessary to switch the expanded memory page frame context between several program modules. There is also a need for a such a method that allows data from a user request to reside in expanded memory, so that a user is not required to write different code depending upon where the TSR or device driver program modules are located.